I started learning game development a couple of months ago, and I just joined my first game jam. The theme was “spin to win”, so I made a marble-rolling game with a twist: a rolling lollipop called Lolli-Roll. Can you handle the stick?

The game jam was The Very Serious Juniper Dev Game Jam and the voting period is still open until July 5, 2026. You can check the Lolli-Roll game on itch.io and rate it for the game jam here .

Lolli-Roll is a physics-based marble-rolling game where the twist is that you are a lollipop. Your movement is imbalanced, and the stick also acts as an obstacle. The original idea was a physics-based rage game, something in the spirit of Egging On, but I could not make a vertical map in one week. I built a time-trial map as the fallback instead.

This was my first game jam game and my second game overall :) It was a hectic week full of work, learning, and fun. I made it in Godot 4.7, which was a pleasure to use. There was no waiting for the editor to open, no slow project loading, and no compile step slowing down every change. That speed helped a lot with iteration.

Struggles

I picked a week-long game jam because before this, I had finished only one game demo, Soma Cube ¹, so I knew I could not make anything playable in a shorter time.

I am a developer, and making games from a developer-first point of view means a lot of refactoring, a lot of code cleanup, and not enough skill yet for making art and game content. I built the time-trial track on the last day, and it shows. I need to spend more time learning how to make my own game assets, especially 3D models.

The biggest planning mistake was time distribution – too much code writing, not enough time dedicated to assets and world building. I also spent a lot of time tweaking the physics-based controls. The lollipop is powered by camera-aligned torque forces, and making those forces feel responsive and satisfying was tedious. Either the controls were too slow, with a large turning radius, or the lollipop was constantly drifting. The controls still need tuning, but I got used to them in the end.

Another last-day problem was that I exported the game for the web for the first time on the last day. Since I am still new to gamedev, here is the obvious advice: export as soon as possible and test how your game behaves in a browser.

There were two main browser problems. First, the game was fighting the browser for the ESC key, because releasing the captured mouse and opening or closing the pause menu wanted to use the same key. The current solution is simple. The game pauses in the browser whenever the mouse cursor is released, and it only unpauses on mouse click, so the click naturally captures the cursor again.

The second problem was some stuttering during gameplay. I noticed similar issues in other game jam entries made in both Godot and Unity. In Godot web builds, this is often caused by compiling shaders on their first use, for example, when rotating the camera toward a new mesh with a new texture or spawning particles for the first time. For an action game, those lags are bad. Collision particles are especially annoying because the game can lag on the first hit.

That kind of lag is rage-inducing for me, so I implemented shader and material precompilation. In Godot, I did this by instantiating each material, applying it to an object, and letting it render for at least one full frame. The whole process is hidden behind a black loading screen with the game logo. After all materials are rendered once, the black screen cross-fades into the game.

Now the game does not lag on the web anymore. It has a so-so time-trial track, I am happy and tired, and the game is submitted. I am very happy that I submitted something playable with at least some purpose :)

Lessons learned

• I can finish a small “game” in a week on my own
• time allocation matters: programming, art, level design, and gameplay testing all need their own space
• testing the web export sooner would have saved me a lot of last-day stress
• an idea is not enough – execution, the level, controls, pacing, and presentation are even more important
• playtest your game – as a developer, you get used to weird controls, camera movement, difficulty, and other sharp edges
• precompiling shaders is a must for web-based action games – compiling shaders is very slow in WebGL
• it was fun, and I will join more game jams

Future plans

I want to improve the game, build proper tracks, add vertical rage-game levels, and implement leaderboards. I also want to tweak the physics-based controls, add physics-altering power-ups, and maybe create new lollipops with different behaviour and looks.